Template talk:Interlinear

Initial trial

This template is in a sort of alpha version. I reckon it will be sensible to consider some basic aspects of it at this early stage, when making changes won't involve fixing existing uses. Comments, suggestions, complaints, ideas and bug reports are welcome. – Uanfala (talk) 00:16, 13 December 2017 (UTC)[reply]

Name of template

What is the most intuitive name for this template? How about the related {{gcl}}: are there more appropriate and/or brief alternative names ({{gloss abbr}}, {{glab}}, {{gloss abbreviation}})? – Uanfala (talk) 00:16, 13 December 2017 (UTC)[reply]

Names of parameters

Are there more intuitive parameter names? I think |glossing= is especially awkward, but I can't think of a better name for it. How about the use of unnamed parameters for each of the lines? This might be messy, but I think a semantically more sensible alternative would make it more difficult to use. – Uanfala (talk) 00:16, 13 December 2017 (UTC)[reply]

Glossing abbreviations

How should glossing abbreviations be formatted by default? As an html abbreviation with the meaning displayed in a tooltip: PFV, or as a link to the Wikipedia article: PFV? – Uanfala (talk) 00:16, 13 December 2017 (UTC)[reply]

Messages in preview mode

When previewing a page, after each invocation of the template there appears a box reporting on the meanings that each glossing abbreviation has been assigned. It is important that glosses are correctly identified as many are used with different meanings in different languages or by different authors, so editors should somehow be "pushed" to review what each abbreviation will be taken to mean. But are these boxes too intrusive? They definitely make the overall page layout in preview mode different from what it appears when saved. – Uanfala (talk) 00:16, 13 December 2017 (UTC)[reply]

HTML output

The html rendering of interlinear text has been adapted from http://bdchauvette.net/leipzig.js/. Comments are welcome, although I think any major overhauls will probably wait until we can use mw:Extension:TemplateStyles (and I don't know when this is going to be deployed on the English Wikipedia). – Uanfala (talk) 00:16, 13 December 2017 (UTC)[reply]

Missing features

Punctuation help

Glosses occasionally employ arcane punctuation: the hyphen as a morpheme boundary is intuitive enough, but the equals sign for a clitic boundary is probably going to catch most readers off guard. Should the template strive to provide some help with such symbols? If yes, then one solution is to format them with <abbr>...</abbr> (like that: =), but these symbols are too small and are usually surrounded by other similarly formatted abbreviations, so that in something like see.PRS=3PL it won't be clear that the symbol is actually an abbreviation of its own. Should they be formatted differently? An alternative would be to scan the glossed text and then build a legend of the punctuation used and display it in some floating (collapsible?) sidebox. Would that be over the top? Or should we leave it to editors to describe in their text the meaning of any symbols they've used? – Uanfala (talk) 00:16, 13 December 2017 (UTC)[reply]

Custom abbreviations

@Uanfala: I haven't studied the template in detail, but I noticed this as an object of concern: The methods mentioned for using custom abbreviations all require the user to include a list into the template call. From the description, the call is likely to often be long and intricate, and challenging to edit and to debug; and including such a list will make it even more so. Someone working on a particular language may well have a set of custom abbreviations that they want to use in many examples and texts. Is it possible to transclude a set of custom abbreviations into the template call? This will be especially necessary when developing a set of abbreviations, so that any revision will be automatically applied to all existing texts. Thnidu (talk) 01:24, 30 January 2018 (UTC)[reply]

Well, the template recognises about 350 of the most commonly used abbreviations, but it's impossible to cover the whole ground, so the situation you're concerned about is quite real. I haven't yet implemented any solution because there was nothing that I was completely happy with. I can think of two workable ways of doing it (and they can sort of be used now without any changes to the template machinery):

Creating a formatted list of custom abbreviations as a dedicated subpage of the article's talk page (we can't do subpages in aricle space unfortunately). This list can then be transcluded into each invokation of the template by setting its ablist parameter to something like that (assuming the subpage is titled glossing abbreviations):

|ablist={{Talk:{{PAGENAME}}/glossing abbreviations}}

Adding the list as an section within the article itself (preferably at the very end) and then similarly transcluding it using labelled section transclusion. The ablist parameter of the template would then look something like that:

|ablist={{#section:{{FULLPAGENAME}}|ablist}}

The list of abbreviations at the end would in turn have a format like the one below:

<section begin=ablist />
<div style="display:none;">
Content of list goes here
</div>
<section end=ablist />

Either of these approaches can be easily built into the template so that it will automatically look for the needed subsection or subpage without users having to type any of the clunky code above. It's really all down to how we decide to go about doing this. What do people think of either of these options? I reckon it's more intuitive to have the list of custom abbreviations within the article, where it can be made to be visible only in editing mode.

I was wary of implementing that straight away because I had concerns about performance. Having each invocation of the template transclude and parse the article is computationally expensive, and there are limits to the the computational resources available for the rendering of each page (when saving or previewing an edit). I've just tested this, and it seems that adding that functionality would increase the processing time by about 35% (if the list is loaded from a subpage) or up to 50% (if it's loaded from within the article). But this seems to have noticeable effects only for bigger articles: for the additional processing time to take one additional second, we'd need an article with several dozen, up to a hundred, instances of the interlinear template. And we won't hit up against the computational limits unless we've got a few hundred such templates (or sooner: other templates within the page also use up resources from the same pool: the citation templates are particularly prominent here). So even though the effect on performance is considerable, this is probably not the issue I initially thought it would be.

At any rate, the most important thing is what the community finds to be the most intuitive way of doing that. Thoughts anyone? – Uanfala (talk) 02:42, 31 January 2018 (UTC)[reply]

I've implemented a version of the second of the two proposed solutions above. Editors will need to add a bit of code at the end of an article, but once that's done each invocation of the template on the article will automatically recognise the abbreviations so defined, without the need to modify the template call. It's not particularly elegant though: having editors deal with a long string of raw html isn't great, but we can't hide that behind a template as labelled section transclusion wouldn't work in that case. – Uanfala (talk) 19:09, 5 May 2019 (UTC)[reply]

June 2019

Hi Uanfala, this looks great! I will experiment with this template in my planned expansion of the grammar section in the article Nias language. If it works smoothly, I will recommended it to like-minded editors who haven't come across it yet.

Just one remark: The output does not appear in default font size in the Desktop view on Chrome Android. It's the same thing with wikitables, and since I guess the underlying format is a table, it won't be easy to fix, right? This is just a minor thing, anyway. On mobile view it comes out nicely, including the horizontal swipe for objects exceeding the view's width. –Austronesier (talk) 11:44, 8 June 2019 (UTC)[reply]

The template doesn't use tables, but floated div elements (it enables wrapping around for longer text or smaller screens, and it's presumably better for accessibility). So I guess the problem shouldn't be necessarily difficult to fix provided we can track it down. I've just had a look using Chrome on Android (both mobile and desktop view) and I'm not able to notice any difference. I do see a smaller first line on Firefox (but that's only if |lang= is set), but in your case the whole interlinear block appears in a different size, not just the first line, right? And is it smaller or larger than the default? – Uanfala (talk) 11:59, 8 June 2019 (UTC)[reply]

Oh yes, that's why it looks familiar, I have the same thing with floated div elements in my blog. And you're right, it is the whole interlinear block which appears smaller than default size, while the third (translation) line is fine, additional elements like |top= also. –Austronesier (talk) 13:07, 8 June 2019 (UTC)[reply]

I would like to replicate this on my machine and see if there's anything I can do. Which version of Chrome are you using? – Uanfala (talk) 18:59, 8 June 2019 (UTC)[reply]

It's version 75.0.3770.67 on Android 6.0.1. –Austronesier (talk) 19:35, 8 June 2019 (UTC)[reply]

Hmmm. Do you see a size discrepancy in both of the following examples?

This

is

a

sentence

This is a sentence.

This

is

a

sentence

This is a sentence.

– Uanfala (talk) 20:02, 8 June 2019 (UTC)[reply]

Both look alike and appear in small font in Desktop view. –Austronesier (talk) 20:11, 8 June 2019 (UTC)[reply]

I don't know what's causing it then. I don't see this problem on my device and I'm using the same version of Chrome (though my Android is 6.0). Could it somehow be due to the different settings we have? To be honest, there are limits on what I can do here: my knowledge of html is quite rudimentary. I've been planning to overhaul the template's html output at some point in the next year or so, so when I get around to it I could see if I'll have learned enough about it all to be able to understand what might be causing the issue. – Uanfala (talk) 20:51, 8 June 2019 (UTC)[reply]

Thanks for your efforts, much appreciated! I'll try to play around with the settings, maybe I'll find something. Anyway, it's just a minor issue which has a simple workaround: pinch-zoom XD. –Austronesier (talk) 21:20, 8 June 2019 (UTC)[reply]

Proposed changes to the default behaviour when deciding which line contains the glosses

Currently, the template assumes by default that the second line of text is the one containing the glosses. There is a proposal to change that behaviour, which will affect uses of the template with either two lines, or with four or more lines of text. The most common uses of the template (with three lines) will not be affected. You're welcome to comment on this proposal. – Uanfala (talk) 14:02, 26 July 2019 (UTC)[reply]

See Module_talk:Interlinear#Comment on proposal and parameter choices. Basically, I'm saying the code shouldn't need to make that decision; instead, it should be an explicit choice made by the user. yoyo (talk) 03:40, 5 September 2019 (UTC)[reply]

No small caps display

Why is "A" displayed as regular cap here?

Mi

IMPF

a-mek'-oñ

2SG.A-hug-1SG.B

'You hug me.'

–Austronesier (talk) 19:24, 9 June 2020 (UTC)[reply]

This also applies to O, P and S, and was apparently deliberate. Kanguole 08:21, 10 June 2020 (UTC)[reply]

Bad news for Mayanists, then. –Austronesier (talk) 12:35, 10 June 2020 (UTC)[reply]

If I recall correctly, the rationale behind this style choice is that small caps should be used only for immediate categories like accusative or ergative, and not for higher-level ones like agent, noun or verb. I don't recall off the top of my head where I got this from, but it must have been the convention used in whatever I was reading at the time. I don't know how common it is, WALS for example (as in here) uses small caps through and through. I can look into it next time I set about working on this template, but for the time being I'll have no objection if anyone comments out or removes the relevant code so that "A" and the rest aren't exempted from small caps formatting (and for individual cases, {{sc}} is always an option). – Uanfala (talk) 13:04, 10 June 2020 (UTC)[reply]

On second thoughts, I'm wondering if I haven't simply been going off our article List of glossing abbreviations. It's got one sentence to this effect in the lead: it was added in this 2013 edit by Kwamikagami. – Uanfala (talk) 13:07, 10 June 2020 (UTC)[reply]

I've always seen A, S and P/O etc. as full caps, and sg, du, pl usually as lower-case, even when longer abbreviations are small cap. I don't know how standardized any of that is, though. — kwami (talk) 14:25, 10 June 2020 (UTC)[reply]

Yeah, something like 1sgA-CAUS-fall-3sgO is common and very much Dixon-style. But current style guides have uniform small caps, e.g. the Leipzig glossing rules. –Austronesier (talk) 14:39, 10 June 2020 (UTC)[reply]

Leipzig only says they're in "upper case letters (usually small capitals)", but they don't illustrate small caps. Dixon-like formatting is more legible, and makes the glossing easier to scan for argument structure -- the one-letter abbreviations can get lost if they're small caps, and sg/pl already have a large digit or 3-letter code to mark the morpheme, so their ubiquity makes them distracting if they're small caps. — kwami (talk) 01:40, 11 June 2020 (UTC)[reply]

Leipzig also has these super-ugly semicolons in the optional Rule 4B :( . –Austronesier (talk) 09:20, 11 June 2020 (UTC)[reply]

Does anyone use those? I've seen colons for that use, never semicolons. — kwami (talk) 03:48, 19 July 2021 (UTC)[reply]

I'm beginning to have doubts about my previous reasoning. I don't recall seeing recent examples of upper-case A or S. Glossa for example has them in small caps, like other abbreviations. Do we have any recent examples of upper-case usage? – Uanfala (talk) 17:31, 31 August 2020 (UTC)[reply]

@Austronesier and Uanfala: There's also the argument in Lehmann (2004) Interlinear morphemic glossing that A, S, O are okay for things like 'AVO word order' (where they would be full caps) but should not be used as interlinear glosses because they're not morphological categories. There would still be e.g. small-cap AT 'agent trigger', as that is a morphological gloss. — kwami (talk) 02:13, 19 July 2021 (UTC)[reply]

A reference grammar that makes the full cap–small cap distinction is Kieviet, Paulus (2017). A Grammar of Rapa Nui. Studies in Diversity Linguistics. Berlin: Language Science Press.

It's freely available online at that link. Full caps are used for A, S, O, also DO for direct object, N and V for noun and verb, and other abbreviations of morphosyntactic categories that do not uniquely identify morphemes, such as LOC locative, QTF quantifier, PND postnominal demonstrative, but he does use small-cap PVP 'postverbal particle' because that's his gloss for a specific morpheme, ai; similarly NUM 'numeral marker' for the morpheme e. — kwami (talk) 19:40, 31 July 2021 (UTC)[reply]

Get rid of the colon

Currently, this template is almost always used with a preceding colon :, so that the block of text is indented:

:{{interlinear|yaba daba doo...}}

This device may be commonly used on talk pages, but it's no good in articles, as it creates bad HTML and leads to accessibility problems (MOS:INDENT, MOS:INDENTGAP). I'm proposing to ditch the colon altogether, and let the template produce the needed indentation by default. In the few instances where someone might need to have a non-indented block of text, they will need to explicitly set |indent= to zero. Any objections, any thoughts? – Uanfala (talk) 20:16, 11 November 2020 (UTC)[reply]

I've been using it with |indent=3. I assume you intend to make that the default if |indent= is not set, i.e. whether |number= is set or not, so that would be a small simplification. Do you plan to use a bot to get rid of all the colons? Kanguole 20:39, 11 November 2020 (UTC)[reply]

Yeah, there will be a default value set in the module. I was thinking of using AWB as that will probably be simpler than a bot, and I would like to be able to manually check for side effects. As for the default value, I haven't really thought of that. The one produced by the colon looks, on my browser, somewhere between 1 and 2. Will 3 look better? – Uanfala (talk) 20:57, 11 November 2020 (UTC)[reply]

3 is similar to what you get with blockquote, and just saying the default is always 3 would be simple. It looks like only 19 pages use :, and one uses ::. Kanguole 22:02, 11 November 2020 (UTC)[reply]

Matching the output of {{blockquote}} sounds like a good idea. But where did you get only 19 uses of the colon? I see 64 [1] (out of 109). – Uanfala (talk) 22:25, 11 November 2020 (UTC)[reply]

I probably missed the other pages. Kanguole 22:28, 11 November 2020 (UTC)[reply]

I also never have used the template without colons. In fact, I'm the two colons ;) I would be fine with a default indent equivalent to 1 colon. For a split second, I thought of an additional feature like some kind of hanging indent, to give room for an optional index; but then, this is WP, not academic writing. What happened to Dative shift after a class assignment is not very reader-friendly. –Austronesier (talk) 10:09, 12 November 2020 (UTC)[reply]

There's a parameter for the optional index (named |number= because the creator of the template doesn't know a thing about typography), as in here:

(3a)

hotch

potch

grotch

hotch

'undefined'

Any ideas for a more sensible name for this parameter? – Uanfala (talk) 16:38, 12 November 2020 (UTC)[reply]

Ok, such much for users who are too lazy to read the manual *facepalm*. Number is good enough I guess. –Austronesier (talk) 16:57, 12 November 2020 (UTC)[reply]

I don't know Lua programming, but would this be as simple as something like changing then indent = args.indent end to then indent = args.indent else indent = "2" end (pseudocode, obviously)? Looking at it some more, that wouldn't quite work, but you want something like "if indent exists and is not zero, set indent to the value, else set it to 2." While allowing number to override indent, if I read the docs correctly. – Jonesey95 (talk) 15:26, 4 April 2021 (UTC)[reply]

Yep, this change is a really simple one. But there are other, unrelated, changes that are planned as well. The idea is to start replacing the colon only once all these changes are implemented. That's because the replacement exercise will be a good way to spot if any new bugs have crept in, and it will also draw attention, via the edit summaries, to functional changes in the new version (which will likely not be constrained to the use of the colon). – Uanfala (talk) 15:47, 4 April 2021 (UTC)[reply]

If this template could be updated soon, at least to fix the indenting, that would be great. The report of articles with the most Linter errors is quite top-heavy with articles that transclude this template. If you are not going to get to it soon, I'm happy to make a pass through the articles to fix the indenting. – Jonesey95 (talk) 13:34, 2 May 2021 (UTC)[reply]

I'm planning to do that within a week. – Uanfala (talk) 13:53, 2 May 2021 (UTC)[reply]

OK, good luck with the fixes. Since these articles have been clogging up the error report for over a month, I have cleaned up Linter errors, including a bunch of misnested italic and bold tags that the unusual parsing of this template can produce, in the most affected articles. I have changed colon markup to |indent= while doing so; if you would like me to return to these articles and reformat them with a script after the template changes are done, I'll be happy to do that. Just drop me a note.

On a possibly related note, I saw at least one template using |num= as a parameter, which did not seem to be valid. If someone can generate a complete list of parameters in the documentation, I'll be happy to implement an unknown parameter check in the template (not in the module), which would categorize unknown parameter usage and add a red error message in preview. This sort of checking is done in many high-use templates, especially infoboxes. – Jonesey95 (talk) 17:22, 10 May 2021 (UTC)[reply]

Bug with unicode entities

This template does not handle unicode designations, e.g. ꞌ for the saltillo. Because the saltillo and 'okina are easily confused with an ASCII apostrophe during editing, it's important to keep them visually distinct in the underlying code. Could someone please fix? Currently Rapa Nui language is a mess; it had started getting corrupted, and it was difficult to tell when editing what was what. — kwami (talk) 06:48, 17 July 2021 (UTC)[reply]

Thanks for spotting this. That's a silly bug: I guess I need to add some code to Module:Interlinear's local function tone_sup(str) to check it doesn't mess up any such html codes. In the meantime, I've replaced ꞌ with direct use of the saltillo itself on the Rapa Nui article – that's easier for editing, and I don't see any benefit in html escape sequences now that browsers don't seem to have any trouble rendering the characters correctly. On an unrelated note, that article consistently uses the lower-case saltillo, even at the start of a sentence, where I'd expect to see the upper-case one (Ꞌ – Ꞌ) instead. Is this on purpose? – Uanfala (talk) 12:53, 17 July 2021 (UTC)[reply]

Hi. The html codes were mainly so that editors could see what they're doing.

As for whether there should be capital saltillos, I don't know if the orthography is that set. But if the following vowel is cap'd, I'd assume the saltillo is not. — kwami (talk) 02:06, 19 July 2021 (UTC)[reply]

Bug: Transliteration |transl=

This module needs some tweaking for the |transl= parameter.

It doesn't recognise transliteration schemes, such as |transl=ja (Japanese)
When it does recognise a valid scheme (e.g. |transl=Hepburn (Japanese)), it doesn't include the appropriate HTML code for accessibility and screen readers. It only includes the "title":

Incorrect HTML [current]:	`<p title="Hepburn transliteration">taiyō ga</p>`	taiyō ga
Correct HTML:	`<p title="Hepburn transliteration" lang="ja-Latn">taiyō ga</p>`	taiyō ga

If anybody is savvy enough to fix this, it would be appreciated. — JKVeganAbroad (talk) 04:17, 18 July 2021 (UTC)[reply]

Thanks for spotting this. The template can't hope to replicate all the complexity of {{transl}} or {{lang}}, but this quick fix should at least deal with this bug. Let me know if anything odd happens again. – Uanfala (talk) 11:31, 18 July 2021 (UTC)[reply]

Brilliant patch! Thank you very much! — JKVeganAbroad (talk) 17:06, 18 July 2021 (UTC)[reply]

Classes 10+

Regarding Bantu noun classes, CL9 works, but CL10 does not. Specifically, I'm trying to transfer over the glosses on the Swahili grammar page to this template. At first I thought that not all off the abbreviations had been listed or something, and so I set up this:

<section begin="list-of-glossing-abbreviations"/><div style="display:none;">
CL10:class 10
CL11:class 11
CL12:class 12
CL13:class 13
CL14:class 14
CL15:class 15
CL16:class 16
CL17:class 17
CL18:class 18
</div><section end="list-of-glossing-abbreviations"/>

And still, the abbreviations don't work. I'm guessing there's some issue with how multi-digit numbers get processed or something? Eievie (talk) 16:44, 4 August 2021 (UTC)[reply]

Ah, yes, that's a bug. There's a piece of code that prevents the template from treating literal numbers (like 25 or 100) as gloss abbreviations (that's so you can gloss for example the Latin centum milites as '100 soldier-PL'). Because it will still need to see for example 3 as the abbreviation for 'third person', the quick solution was to check if the word contained two or more digits, and stop treating it as a gloss abbreviation if it was. And here's the bug: this should happen not to words containing 2+ digits, but only to those consisting entirely of 2+ digits. I've fixed that now [2]. It should work now, and there's no need to define individual classes – they should get recognised off the bat. – Uanfala (talk) 21:22, 4 August 2021 (UTC)[reply]

Might I suggest something like, if it begins with a digit, don't gloss. If it begins with a letter and contains digits (however may) after that, gloss. I'm not sure about the details, but at first glance at least, that seems like it would be a solution to support both situations. - Eievie (talk) 22:55, 4 August 2021 (UTC)[reply]

But we still want for 1 to be glossed (as 'first person'), right? – Uanfala (talk) 23:28, 4 August 2021 (UTC)[reply]

PROX

Can we add "PROX" for "proximal" as an abbreviation? It's super common, glosses use it all the time. Eievie (talk) 02:08, 12 August 2021 (UTC)[reply]

There's an entry for "PROX" in Module:Interlinear/data, but it's deliberately empty and flagged as ambiguous: the abbreviation can be used for both proximal (i.e. not distal), and proximate (i.e. not obviative). – Uanfala (talk) 10:30, 12 August 2021 (UTC)[reply]

Proximal is so common, though, and proximate is so uncommon. I think that overwriting PROX in the context of proximate would be reasonable enough. Eievie (talk) 06:36, 13 August 2021 (UTC)[reply]

Invalid gloss abbreviations

Is anyone here paying attention to Category:Pages with errors in interlinear text? I don't know whether these errors need to be fixed in the articles, or in the module, but editors are introducing many gloss abbreviations that the module is flagging as errors. Pinging Eievie, who appears to have added many of these abbreviations. – Jonesey95 (talk) 14:18, 2 September 2021 (UTC)[reply]

Yeah, some glosses have problems. The number of words in the different lines don't match up, or there are abbreviations of unclear meaning. My basic philosophy, though, is that even without the interlinear template, these errors are still there. Words not matching up, or unclear abbreviations, are still confusing, still a problem. Yes, you could use glossing=no abbr to hide "error, abbreviation unknown" message. But I don't think we should paper over the cracks. If an unclear abbreviations is used, that should be highlighted, so that someone can either go to the trouble of figuring out what it was supposed to mean and fixing it, or removing the gloss entirely. (In some cases, I have looked up the sources these glosses come from, found the abbreviations on that paper's list of abbreviations, and added it.) --Eievie (talk) 16:53, 2 September 2021 (UTC)[reply]

Because it touches the same subject, it would be good to synchronize the template with List of glossing abbreviations. It used to just provide glosses as they were encountered in the literature, but about two years ago, we singled out a separate "conventional gloss" column, and as this is now relatively mature, it could guide fixing unclear abbreviations and populating the template. Chiarcos (talk) 06:14, 10 March 2023 (UTC)[reply]

The template gets its natively recognised abbreviations from Module:Interlinear/data, so that would be the page to update. – Uanfala (talk) 12:37, 10 March 2023 (UTC)[reply]

Klingon

I'm setting up Klingon's glosses with template (lang=tlh) and it has some very specific formatting requirements: bold, monospace text. Could that be set up? Like maybe the {{mono}} template? --Eievie (talk) 17:12, 29 September 2021 (UTC)[reply]

Take a look at "Style monospace, no italics, bold" on the testcases page for an example of how to get bold, non-italic, monospaced text in the first line. – Jonesey95 (talk) 18:30, 29 September 2021 (UTC)[reply]

Yeah, that's exactly how it's meant to be done. But I'm wondering: if this isn't a single article's stylistic choice and if Klingon is meant to be displayed like that across the board, then it may be easier to just adopt a Wikipedia-wide class for Klingon text and then invoke the template with just class1=klingon? – Uanfala (talk) 20:04, 29 September 2021 (UTC)[reply]

Is there some sort of MOS that dictates this unusual display of Klingon text? I am seeing monospaced italics in Klingon language (the string "bold" does not appear in that article). We generally use normal italics for Roman scripts of non-English languages. – Jonesey95 (talk) 21:26, 29 September 2021 (UTC)[reply]

Addendum: Monospace font + bold is the convention the page uses, but from what it says, only monospace is actually necessary (because Klingon uses uppercase letters in weird ways, and I and l need to be distinguishable). Eievie (talk) 02:27, 30 September 2021 (UTC)[reply]

It would probably be best to use a standard gloss rather than an unusual bolding; that is probably just someone's choice, but it is better to be consistent among articles. To get mono non-italic, use the testcase's code without the bold part. – Jonesey95 (talk) 03:23, 30 September 2021 (UTC)[reply]

On Klingon grammar I've done some with style1= font-family:monospace; and it works. But if there could be some sort of default for things with lang=tlh that would certainly be easier. Eievie (talk) 22:53, 2 October 2021 (UTC)[reply]

The use of monospace is purely conventional too. That virtually all monospace fonts make the difference between I and l clear has nothing to do with their monospaciness and most serif fonts do the job equally well. But obviously, something has to be done and monospace is something that works, but it's not strictly necessary. – MwGamera (talk) 14:40, 2 April 2023 (UTC)[reply]

hamza

In the Chamorro language, the hamza template isn't working inside an interlinear

(1)

Ha-faʼgasi

3SG.SA-wash

si

PND

Juan

i

the

kareta.

car

'Juan washed the car.'

Is there a way to fix this? Eievie (talk) 23:52, 15 December 2021 (UTC)[reply]

That template contains a number followed by a letter. Per this template's documentation: On italicised lines, tone numbers will be formatted as superscripts, unless |tone-superscripting= is set to no and Any single digit following an alphabetical character is treated as a tone number. I have set |tone-superscripting=no above, and it seems to render as desired. – Jonesey95 (talk) 01:00, 16 December 2021 (UTC)[reply]

Jonesey95 is correct about the source of the problem. Ideally, the template will be expanded with a bit of code that checks for html escape codes (like the ʼ produced by {{hamza}}), so this doesn't happen again. Until then, a better solution in my view is to get rid of {{hamza}} and use the unescaped character ʼ directly – that makes for an overall simpler source text. – Uanfala (talk) 20:41, 19 December 2021 (UTC)[reply]

...and to run the risk of getting charming comments such as this one[3]... –Austronesier (talk) 21:15, 19 December 2021 (UTC)[reply]

That comment is right though. A normal apostrophe, or as in the case of the Levantine Arabic article before Trappist's edit – the right curly quotation mark – should never be used to represent letters (like the Arabic hamza or the glottal stop in Chamorro). One appropriate symbol is the modifier letter apostrophe (the one that {{hamza}} outputs). That symbol won't get replaced by a straight apostrophe by the people who engage in those script-assisted edits. – Uanfala (talk) 21:38, 19 December 2021 (UTC)[reply]

Uhm yeah I see now. On my phone it's all tiny marks...–Austronesier (talk) 22:08, 19 December 2021 (UTC)[reply]

They look identical to me too, but they behave very differently. One counts as punctuation, the other – as a letter (or was it a letter element?) and that affects how words are parsed by the software. You can see the difference if you double-click on a word and see if the correct sequence of letters is selected: fa’gasi (with a quotation mark) vs. faʼgasi (modifier letter). – Uanfala (talk) 22:54, 19 December 2021 (UTC)[reply]

copying to EN Wikibooks

I saw Eievie started to duplicate it there but it didn't seem to work. I added the /doc so it at least shows up, albeit in a brokenish way. Any help would be appreciated. Arlo James Barnes 23:07, 20 February 2022 (UTC)[reply]

In order to make the documentation work, you need to copy all of those redlinked templates over as well. If you click on "Edit source" and then fold down the list of "Templates used on this page:", anything in red needs to be copied (or created as a redirect to an identical template). – Jonesey95 (talk) 23:24, 20 February 2022 (UTC)[reply]

Ah, got it; thank you. I just noticed that someone mentioned on Eievie's talk page that WB:RfI is the proper venue to do this sort of thing, so I'll ask there next. Arlo James Barnes 23:29, 20 February 2022 (UTC)[reply]

The documentation aside, the template itself seems to work there. Are there any problems with that? – Uanfala (talk) 23:47, 20 February 2022 (UTC)[reply]

Yes,@Uanfala: it seems that custom glosses that start with a global gloss don't get recognised. In my case, Láadan has different possessive affixes depending on the manner of possession, and setting |glossing=link and |ablist= doesn't seem to result in a link or a hover definition if the gloss starts with POS (such as POSbirth). Arlo James Barnes 07:53, 27 February 2022 (UTC)[reply]

One major current limitation of the template is that it will recognise gloss abbreviations only if they're in all caps (with a few hard-coded exceptions like "Fsg"). This may change in a future version.

Now, assuming you've already defined POSS and BIRTH, the template won't recognise POSSBIRTH as a combination of the two (it sees that as a single gloss). You can either separate the two units with one of the standard pieces of punctuation used in such cases (like POSS.BIRTH or POSS;BIRTH) or – if you wouldn't like to use punctuation – define POSSBIRTH separately.

To use a custom-defined gloss that's not in all capitals, the solution is to use {{gcl}}: {{gcl|Abbreviation|Meaning|Link}}: POSbirth. You can use that template from within {{interlinear}} as well. Its downside is that it can't access the definitions of abbreviations that are set elsewhere on the page, you'll have to write them out each time. – Uanfala (talk) 15:06, 27 February 2022 (UTC)[reply]

This would've been a while ago, and honestly I don't remember what happened anymore, but I thought I was told 'no importing templates' so I stopped halfway through? Eievie (talk) 01:07, 21 February 2022 (UTC)[reply]

Yeah, I saw that on your user talk there right after posting this, although I read it more as 'yes importing templates, but we have a certain way of going about it that preserves edit history'.

@Eievie: Mrjulesd is helping out with that process now, but it has been a little snaggy so far. Arlo James Barnes 07:53, 27 February 2022 (UTC)[reply]

Similarly numbered template for translations?

The article "Dative shift" uses this template (with its number parameter) to provide numbered and glossed examples. It also has examples with translations but without glosses, for which it uses :-indented lines, which don't look nearly as pretty. Is there a template that would format those nicely, with numbers like this template, but without expecting an interlinear gloss? A PetScan search for "Layout templates" ∩ "Linguistics templates" didn't turn up any. Perey (talk) 06:19, 9 July 2022 (UTC)[reply]

I think his template can sort of be tweaked to work with situations like that. But I'm wondering if there isn't a dedicated template for what you're describing. There's {{Text and translation}} and its relatives, but they place the original text and the translation side by side, so they're not going to work here. Any chance SMcCandlish or Jonesey95 may know of something? – Uanfala (talk) 13:24, 10 July 2022 (UTC)[reply]

Nothing I'm aware of. — SMcCandlish ☏ ¢ 😼 19:01, 10 July 2022 (UTC)[reply]

I don't know of one. – Jonesey95 (talk) 17:05, 11 July 2022 (UTC)[reply]

Two-number tones

Habei language has tone numbers. Before the interlinear gloss template was introduced, it looked like this and they wrote the tones with unicode superscript numbers. When I moved the glosses over to the template I replaced them with regular numbers because the template takes care of that. But the tones in this instance involve strings of 2 or 3 numbers in a row, and the template only deals with the first. Is there any workaround for that? Eievie (talk) 06:00, 13 December 2022 (UTC)[reply]

This is a bug down to a simple omission. Should be fixed now [4]. – Uanfala (talk) 13:48, 14 December 2022 (UTC)[reply]

Wonderful, thank you so much! Eievie (talk) 02:26, 22 December 2022 (UTC)[reply]

Saltillo

The {{saltillo}} template causes issues within {{interlinear}}. Can that be fixed? Eievie (talk) 18:34, 26 December 2022 (UTC)[reply]

What sort of problems? Perhaps link to your sandbox page, or an article, or the testcases page for this template. – Jonesey95 (talk) 18:43, 26 December 2022 (UTC)[reply]

Like in the Luiseño language:

Lovíꞌi

Do

om

you

hish

anything

mimchapun

whatever

iváꞌ

here

ooxng

earth-on

tuupanga

sky-in

axáninuk.

as

Eievie (talk) 01:29, 27 December 2022 (UTC)[reply]

This is a bug that I'm planning to try to fix whenever I get back to working on the next version of the template, and it's unlikely that I'll have the time in the next couple of months. In the meantime, you can simply use the saltillo character ꞌ directly: that way, the wikicode will arguably be more readable too. – Uanfala (talk) 13:05, 27 December 2022 (UTC)[reply]

Interaction with floats

Take a look at Allocutive agreement. There is a huge gap before the first interlinear for no apparent reason. It seems to be caused by the images floating on the right side, but I'm not exactly sure why, as they use float:right and clear:right while interlinear uses left. Is there any good way around it? – MwGamera (talk) 14:22, 2 April 2023 (UTC)[reply]

IPA and italics

Since IPA should not be presented in italics, perhaps |ipaN=yes should imply |italicsN=no. Kanguole 13:21, 24 August 2024 (UTC)[reply]